Linux Hardening in Hostile Networks by Rankin Kyle

Author:Rankin, Kyle
Language: eng
Format: epub
Publisher: Pearson Education Limited (US titles)
Published: 2017-11-25T05:00:00+00:00

Section 1: Web Server Security Fundamentals

Even though the Internet comprises a number of different services including email, DNS, and chat protocols, when your average user thinks about the Internet, they probably think about web services. It’s understandable when you consider that, in addition to websites, even email and chat services are most commonly accessed via a web browser today.

Permissions

The first thing to consider when hardening a web server is permissions. Since only root users can open ports below 1024, web servers typically need some level of root privilege when they start so they can open port 80 and 443. In the past, this meant that web servers ran as root the entire time and any compromise of that web service meant the attacker had root privileges. As a result, many web server−hardening guides devoted a fair amount of time to sandboxing or otherwise working around the root privilege issue.

Fortunately, these days most Linux distributions do a good job of providing initial hardening for web servers they package. Most web servers start up as root to open low ports, but then drop root privileges to an unprivileged system user like nobody or www-data to serve files or run CGI scripts. This means that if an attacker compromises your web application, he won’t automatically have root privileges. Of course, the attacker will still have whatever permissions the unprivileged user has, which is often good enough for his needs. For instance, with web server privileges, he might be able to change files the web server is hosting and he can access any downstream services the web user can. Local access can also be used to get root through a local privilege escalation exploit on a vulnerable system.

Since root privileges are taken care of, the first hardening step you should take is to audit the permissions on any document roots or files your web server hosts. For instance, /var/www/html is a default document root on Debian-based systems. Ideally, the unprivileged user will be able to read, but not write to, files the web server hosts. So if the document root is owned by the root user and root group, for instance, you would want to make sure that any directories are world readable and executable (chmod 755) and files inside are only world readable (chmod 644). Alternatively, if you wanted to avoid having world-readable files in your document root, you could change the group ownership to match your web server’s unprivileged user (chgrp www-data filename) and change permissions on directories to 750 and files to 640 to remove any world readable status.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.